優化嘗試

根據昨日的結論，對於日益增加的資料量，使用自建機房成本效益並不大，那要怎麼做效能以及成本的優化呢？

看起來只能從查詢時的讀檔費用中來著手了，降低過多 Metadata / Menifest 讀取，就能降低 Trino cluster 的工作負荷以及 S3 I/O 費用，這邊就列出筆者有嘗試的優化：

• 雖說 iceberg 對於 metadata 的設計良好，但還是得定期清理較舊的 expire_snapshots 以釋放空間，增加查詢效能：

-- 清掉保留超過兩天的 snapshot metadata
-- 包含 metadata file、manifest file
ALTER TABLE {table_name} EXECUTE expire_snapshots(retention_threshold => '2d')

• orphan_files 顧名思義就是沒被引用的「孤兒」檔案，與 expire_snapshots 的差別在於此操作會刪除無主的「實體檔案」

-- 清掉超過兩天未被任何 snapshot 引用的檔案
-- 包含 metadata file、manifest file、data file
ALTER TABLE {table_name} EXECUTE remove_orphan_files(retention_threshold => '2d')

• 因為 Iceberg metadata 會紀錄 欄位統計值 以加快查詢，當欄位長大統計值也會跟著變肥，故需要定期使用 drop_extended_stats 去清理：

-- 清理欄位統計值
EXECUTE drop_extended_stats

• 而統計值被清掉之後，當然需要重建並將更準確的統計值存回 metadata 中，這時候就需要使用 ANALYZE TABLE 的操作：

-- 重建 table 欄位統計值
ANALYZE {table_name}

排程作業

每次都要動手下語法太麻煩了，所以目前筆者公司是用 Airflow 搭配 TrinoHook 每週定期去清一次，由於這座 Trino 放的資料屬於冷資料，所以不需要太頻繁的做清理，不過一次要清理一個禮拜的量還是需要一點時間 (約 6 個小時左右) 。

還能做什麼

下面是 Trino 文檔有提到但筆者尚未嘗試過的優化：

Rewrites manifest files to cluster them by partitioning columns.
This can be used to optimize scan planning when there are many small manifest files or when there are partition filters in read queries but the manifest files are not grouped by partitions.

亦即重新將沒有照 partitions 欄位擺放的 manifest files 做重寫，旨在降低下次查詢的掃檔成本：

ALTER TABLE test_table EXECUTE optimize_manifests;

而效果如何呢？雖非很嚴謹的實驗，筆者公司 Trino cluster 發查又有尖峰與離峰，但可從下圖大致知道，trino_execution_querymanager_wallinputbytesrate_fiveminutes_avg 此指標紀錄平均五分鍾內對 S3 的 I/O throughput，在完成 optimize job 後確實下降不少，表示讀取變有效率了。

成本的部分就比較有感了，筆者從 Airflow 將第一次執行 trino_optimize_iceberg 的時間撈出來 (2025.02)，比較執行前後兩個月的成本變化，每月下降了 40%，可謂顯著下降。

-- 第一次執行 trino_optimize_iceberg 之時間
airflow-metadata=> 
SELECT 
    dag_id, 
    MIN(start_date) AS first_run_time
FROM 
    dag_run
WHERE 
    dag_id = 'trino_optimize_iceberg'
GROUP BY dag_id;

         dag_id         |        first_run_time
------------------------+-------------------------------
 trino_optimize_iceberg | 2025-02-04 07:26:21.016733+00

明日預告

在全面理解 Iceberg 的優缺點後，《為什麼我改用 Iceberg (一)》將於明日揭開序幕。
本文將從公司角度切入，分享我們是如何評估，並思考是否要將原本廣受好評的 Google BigQuery，替換為 Trino + Iceberg on S3。

Know me more

My Linkedin: https://www.linkedin.com/in/benny0624/
My Medium: https://hndsmhsu.medium.com/